With the explosive growth of today's information superhighway have come the inevitable traffic jams. Congestion is a serious problem today on the Internet, a worldwide system of computer networks using packet-switching technology to transfer messages between computers. Packet-switching protocols such as the Transmission Control Protocol/Internet Protocol (TCP/IP) divide messages into packets which travel along a path in the network that can be varied as conditions in the network change. Specifically, TCP/IP, as currently implemented in the Internet, routes packets independently of each other, utilizing its best efforts without any specific concept of a “connection.” Accordingly, in the Internet, there is little notion of “quality of service”, no notion of guaranteed throughput, and no notion of bounded transmission delay.
Current implementations of TCP/IP rely on packet loss as an indicator of congestion in the network. As the network experiences congestion, data flowing through a network router becomes bottlenecked in a queue until the queue overflows and packets are lost. Load reduction is accomplished by utilizing a well-known “congestion avoidance” algorithm first described by Van Jacobson in 1988. See “Congestion Avoidance and Control,” V. Jacobson, ACM SIGCOMM-88, August 1988, p. 314–29; “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms,” W. Stevens, RFC 2581 (revision of RFC 2001), which is incorporated by reference herein. In what is coined a “slow start”, a TCP source begins inserting packets into the network by starting with a minimal congestion window, allowing at most one unacknowledged packet in the network. Each time an acknowledgement (ACK) is received, the congestion window is enlarged exponentially until a first threshold is reached or until a packet is dropped. If the first threshold is reached, the TCP source continues to enlarge the congestion window linearly until either a second threshold is reached—or until a packet is dropped. Upon the timeout of a retransmit timer (thereby indicating a dropped packet), the TCP source reduces the transmission rate and “backs off” to its minimal window, with the goal of allowing the network to reach some form of equilibrium.
As traffic on the Internet increases and more applications are run which are sensitive to the delay caused by dropped packets (e.g. streaming audio and video), proposals have emerged to add some form of explicit congestion notification (ECN) to TCP. See “TCP and Explicit Congestion Notification”, ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10–23; “A Proposal to add Explicit Congestion Notification (ECN) to IP”, K.K. Ramakrishnan and Sally Floyd, RFC 2481, which is incorporated by reference herein. For example, a network router with a queue nearing an overflow, rather than merely waiting for a packet to drop, can transmit a signal (in the form of a special bit in the packet's header) to indicate the presence of network congestion. The receiver's acknowledgment packet passes the notification on to the sender, which in turn slows down its transmission rate.
These methods of controlling congestion by signaling for a reduction in transmission rate, however, do not address the root problem—namely, insufficient transmission capacity to support the explosive growth in the number of users demanding access to the Internet at the same time. Short of increasing the capacity of the network, these methods of addressing congestion can make performance degradation more gradual, but they cannot prevent it altogether. It would be preferable to establish a system that reduced congestion in the network by affecting the network usage habits of the people accessing the Internet, and thereby directly addressing the problem of overrunning the capacity of the network.